This section is intended to provide a background or context to the invention that is recited in the claims. The description herein may include concepts that could be pursued, but are not necessarily ones that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, what is described in this section is not prior art to the description and claims in this application and is not admitted to be prior art by inclusion in this section.
A Presence Service is a network service which accepts, stores and distributes Presence information. Presence information typically comprises a status indicator that indicates the ability and willingness of a communication partner to communicate.
Presence Service can be linked with many other services or enablers. “Horizontal” Presence Services can be used as the launching pad for a different type of communication. Moreover, Horizontal Presence Services can be used to circulate personal and device-specific information to a selected set of authorized Watchers. (A Watcher or Presence Information Watcher is an entity that requests Presence information about a Presentity (an entity described by Presence information) from a Presence Service.) However, all of these services can collectively cause a great deal of Presence traffic.
Due to the nature of Presence Services, a simple change in one's Presence information can cause a significant amount of traffic in a network. Additionally, the integration of location information within a Presence Service can be quite demanding in terms of traffic. For example, it is helpful to consider a situation where an entity is uploads its location information whenever this information changes. In this situation, if the location of the entity is regularly changing, then a great deal of network traffic is generated.
Because of the traffic-related issues discussed above, there have been a number of efforts attempted to improve the traffic situation. In one such arrangement intended to improve Presence traffic, upon receiving any subscription request from a Watcher, the Presence Server makes a back-end subscription for the Presence Information to the associated Presence Source in the network (i.e. a Presence Network Agent (PNA)). Therefore, the PNA uploads Presence Information in terms of a notification to the Presence Server, which then makes the Presence Information available to the Watcher. In another system, upon receiving any subscription request from a Watcher, the Presence Server uses a Session Initiation Protocol (SIP) REFER request to inform the associated Presence Source about the need of Presence Information. In response, the Presence Source uploads Presence Information using a SIP PUBLISH request to the Presence Server, which then makes the Presence Information available to the Watcher.
However, the need to further reduce the amount of Presence-related traffic remains. In particular, the above systems cannot indicate what specific Presence Information is required, if any, and they also introduce new protocol procedures. Therefore, the Presence Source still needs to publish all available Presence Information about a Presence Entity (Presentity). Issues also remain regarding authentication and authorization (i.e. security), Presence Source discovery and routing.
Additionally, it is also noted that, according to the existing model of Presence, the publication of Presence information is carried out independent of subscription. For example, there is no point for a Presence Source to publish Presence Information, if there is no subscription (demand) for that information. If a Presence Source is publishing dynamic Presence information (e.g. location information), the demand for the information should be understood before the information is published. It is possible that Presence Information about a Presentity may be required only at a specific time (e.g., a moment of interest) and not on a frequent basis. It is also possible that only specific Presence information may be required, i.e., not all of Presence Information.